\documentclass[a4paper,12pt]{article}

\usepackage{fancyhdr}
\usepackage[utf8]{inputenc}
\usepackage{polski}
\usepackage[polish]{babel}
\usepackage{a4wide}

\pagestyle{fancy}

\renewcommand{\headheight}{16pt}

\newcommand{\HRule}{\rule{\linewidth}{0.1mm}}

\begin{document}

\begin{titlepage}
\begin{center}
	\textsc{Inżynieria oprogramowania - Grupa dra inż. Leszka Grocholskiego}\\
	\textsc{II UWr 2009/2010}\\[4cm]

	\HRule \\[2cm]

	Aleksandra Kloc, Adam Grycner, Mateusz Łyczek\\[1cm]

	\textsc{\Large Wasza-fota.pl}\\[0.3cm]
	\textsc{\large Plan testowania}\\[2cm]

	\HRule\\[2.5cm]
	
\begin{center}
\textbf{Historia zmian tego dokumentu}
\end{center}
\begin{table}[h]
	\begin{center}
	{\footnotesize
	\begin{tabular}{|l|c|p{2.8cm}|l|}
		\hline
		\textbf{Data} & \textbf{Wersja} & \textbf{Autor} & \textbf{Opis zmian}\\
		\hline
		2009/12/15 & 1.0 & Zespół & Utworzenie dokumentu\\
		2009/12/15 & 1.1 & Mateusz Łyczek & Narzędzia wspomagające, Testy, Harmonogram testów\\
		2009/12/17 & 1.2 & Aleksandra Kloc & Testy przypadków użycia\\
		\hline
	\end{tabular}
	}
	\end{center}
	\caption{Historia zmian}
\end{table}
	
	
\end{center}
\end{titlepage}

\tableofcontents
\newpage

\section{Wstęp}
Testowanie jest jednym z najważniejszych etapów wytwarzania oprogramowania, dlatego w projekcie \emph{Wasza-fota.pl} poświęcona jest mu duża
uwaga. Niniejszy dokument zawiera opis procesu testowania jaki został przyjęty dla tego projektu.

\section{Narzędzia wspomagające\label{S:narzedzia}}
Przedstawione niżej narzędzia zostały wybrane ze względu na ich znajomość w zespole programistów i testerów. Będą one im pomagały w sprawniejszym,
dokładniejszym i szybszym przeprowadzaniu testów, a przez swoją darmowość nie zwiększą kosztów.

\subsection{Testowanie kodu PHP}
Do testowania kodu \verb+PHP+ zostanie użyty pakiet \verb+SimpleTest+, który jest narzędziem do tworzenia testów jednostkowych i ich
automatycznego przeprowadzania dla języka \verb+PHP+.

\subsection{Testowanie kodu Python'a}
Do wspomagania tworzenia testów jednostkowych w języku \verb+Python+ i ich automatycznego przeprowadzania użyty zostanie pakiet \verb+PyUnit+,
który jest wzorowany na systemie \verb+jUnit+, powszechnie znanym wśród programistów i testerów.

\subsection{Testowanie interfejsu}
Interfejs portalu, który jest stroną internetową wyświetlaną przez przeglądarki internetowe będzie testowany przy pomocy programu \verb+HttpUnit+,
kolejnego narzędzia wspomagającego przeprowadzanie testów jednostkowych. Pozwala on automatycznie (przy pomocy np. pakietu \verb+jUnit+) testować
zachowanie webowego interfejsu użytkownika włącznie ze skryptami \verb+JavaScript+.

\subsection{Testowanie wydajności}
Tworzony portal ma być szybki, dlatego jego wydajność też musi być przedmiotem testów. Do tego celu wykorzystany będzie program
\verb+Apache JMeter+, napisany w \verb+Javie+ i służący właśnie m. in. do symulowania dużego obciążenie systemu oraz ogólnej wydajności aplikacji.


\section{Testy modułowe}
Testy modułowe to testy specyficzne dla danego modułu lub klasy. Każdy programista będzie odpowiedzialny za przetestowanie klasy którą napisał
(jeśli klasę lub moduł pisało więcej programistów, wtedy kierownik podprojektu wyznacza konkretną jedną osobę, która będzie odpowiedzialna
za przetestowanie danej klasy lub modułu). Dla każdej klasy i modułu powinna być napisana klasa testująca przy użyciu opisanych wyżej narzędzi.
Dodatkowo testerzy będą niezależnie testować każdą klasę (być może wykorzystując testy programisty i rozszerzając je).


\section{Testy integracyjne}
Ten typ testów sprawdza niezawodność i poprawność komunikacji między poszczególnymi modułami aplikacji. Przed ostateczną integracją nowego modułu
z całym systemem musi on zostać zaakceptowany przez testerów. Symulują oni integrację modułu z systemem na jego kopii i sprawdzają, czy wszystko
działa poprawnie. Dopiero po ich akceptacji, moduł może zostać zintegrowany z systemem. W przypadku negatywnego wyniku testów do programistów
odpowiedzialnych za dany moduł trafia raport testerów, który opisuje znalezione błędy. Taka procedura gwarantuje nam, że system w pełni działa
po każdej integracji do niego nowego modułu.


\section{Testy systemowe}
Testy systemowe to testy sprawdzające działanie całego systemu, w szczególności poszczególnych funkcji, która aplikacja ma wykonywać.
Po integracji z systemem wszystkich modułów odpowiedzialnych za obsługę danej funkcji testerzy przystępują do jej testowania. Nacisk kładziony
tutaj jest już także na zachowanie interfejsu użytkownika, dlatego intensywnie wykorzystywany będzie w tym etapie pakiet \verb+HttpUnit+,
ale także pozostałe. Testowane będzie poprawne zachowanie w każdy przypadku użycia dotyczącym danej funkcji, sprawdzane będzie też zachowanie
aplikacji na otrzymanie niepoprawnych danych. Testy w tej części wykonywane będą dwojako:
\begin{itemize}
	\item \textbf{w sposób zautomatyzowany} - przy wykorzystaniu narzędzi do testów jednostkowych opisanych w sekcji \ref{S:narzedzia}.
	       Testy te będą tak szczegółowe jak tylko jest to możliwe w przypadku automatycznego testowania, aby sprawdzić jak najwięcej
	       miejsc mogących powodować błędy,
	\item \textbf{ręcznie przez testerów} - w przeglądarkach internetowych. Niektórych rzeczy nie da się przetestować w sposób automatyczny.
	       Dlatego testerzy oprócz testów automatycznych będą też ręcznie testować aplikację w przeglądarkach internetowych, sprawdzając przy
	       okazji zachowanie w każdej z najpopularniejszych obecnie przeglądarek. Testerzy będą wykonywać po kolei kroki poszczególnych
	       przypadków użycia i sprawdzać, czy są poprawnie realizowane. Oprócz tego będą się na wszelkie sposoby złamać system bądź mu
	       zaszkodzić, co ma na celu wykrycie błędów związanych z bezpieczeństwem danych na portalu.
\end{itemize}

\subsection{Testy przypadków użycia}
Przedstawione teraz zostaną przykładowe testy przypadków użycia wraz z oczekiwanymi wynikami. Dla każdego opisanego testu przypadku użycia
podano wejście, czyli jakie czynności są wykonywane przez testerów. Wyjście określa zachowanie oczekiwane od systemu w zaistniałej sytuacji.
\subsubsection{Logowanie}
  \begin{itemize}
    \item \emph{Próba zalogowania się do systemu z poprawnym loginem i hasłem}\\[0.3cm]
          \textbf{wejście}: w odpowiednich polach wpisujemy poprawne hasło i login\\[0.2cm]
          \textbf{wyjście}: system wyświetla odpowiednią stronę główną zalogowanego użytkownika w zależności od rodzaju konta

    \item \emph{Próba zalogowania się do systemu z poprawnym loginem i niepoprawnym hasłem}\\[0.3cm]
          \textbf{wejście}: w odpowiednich polach wpisujemy poprawny loginem i niepoprawne hasło\\[0.2cm]
          \textbf{wyjście}: system ponownie wyświetla formularz logowania z dodatkowym komunikatem o podaniu niepoprawnego hasła i prośbą
          o ponowne wypełnienie formularza

    \item \emph{Próba zalogowania się do systemu z nieistniejącym loginem}\\[0.3cm]
          \textbf{wejście}: w odpowiednich polach wpisujemy nieistniejący login i hasło\\[0.2cm]
          \textbf{wyjście}: system ponownie wyświetla formularz logowania z komunikatem o braku podanego użytkownika w bazie i prośbą o ponowne
          wypełnienia formularza

    \item \emph{Próba zalogowania się do systemu z niewypełnionym polem hasła lub loginu}\\[0.3cm]
          \textbf{wejście}: w odpowiednim polu wpisujemy login albo hasło, a drugie pole pozostawiamy puste\\[0.2cm]
          \textbf{wyjście}: system ponownie wyświetla formularz logowania z dodatkowym komunikatem o brakujących danych w formularzu
  \end{itemize}

\subsubsection{Zmiana profilu}
  \begin{itemize}
    \item \emph{Użytkownik naciska przycisk ``Profil'' i źle wprowadza dane do formularza}\\[0.3cm]
          \textbf{wejście}: źle wprowadzamy nowe dane do formularza, np: nie wypełniamy obowiązkowego pola, w systemie istnieje już
          użytkownik o podanym loginie lub adresie e-mail, wprowadzamy hasło różne od jego potwierdzenia lub krótsze niż 5 znaków\\[0.2cm]
          \textbf{wyjście}: system wyświetla informacje o błędzie (określając na czym polega błąd) obok odpowiednich pól, umożliwiając
          poprawienie danych (zawartość pól wypełnionych poprawnie nie jest usuwana)

    \item \emph{Użytkownik naciska przycisk ``Profil'' i poprawnie wprowadza dane do formularza}\\[0.3cm]
          \textbf{wejście}: wprowadzamy poprawne dane w formularzu\\[0.2cm]
          \textbf{wyjście}: system wyświetla komunikat o zatwierdzeniu zmian wprowadzonych w profilu użytkownika
  \end{itemize}

\subsubsection{Utworzenie galerii}
  \begin{itemize}
    \item \emph{Użytkownik naciska przycisk ``Galerie'' i źle wprowadza dane do formularza}\\[0.3cm]
          \textbf{wejście}: źle wprowadzamy dane do formularza, np: nie wypełniamy obowiązkowego pola, w systemie istnieje już galeria
          o podanej nazwie i dacie utworzona przez danego fotografa, wprowadzone hasło dostępu do prywatnej galerii
          jest różne od jego potwierdzenia lub krótsze niż 5 znaków\\[0.2cm]
          \textbf{wyjście}: system wyświetla informacje o błędzie (określając na czym polega błąd) obok odpowiednich pól, umożliwiając
          poprawienie danych (zawartość pól wypełnionych poprawnie nie jest usuwana)

    \item \emph{Dodany plik ze zdjęciami nie spełnia narzuconych warunków}\\[0.3cm]
          \textbf{wejście}: dodajemy do formularza plik ze zdjęciami niespełniający warunków stawianych przez system tzn: nie ma wystarczająco
          dużo miejsce w pakiecie lub rozmiar zdjęć jest za duży lub ilość zdjęć w pakiecie przekracza maksymalną wartość\\[0.2cm]
          \textbf{wyjście}: system wyświetla odpowiedni komunikat i wymaga dokonania zmiany w wyborze pliku

    \item \emph{Dodany plik ze zdjęciami spełnia narzucone warunki}\\[0.2cm]
          \textbf{wejście}: wprowadzamy poprawne dane w formularzu i dodajemy do formularza plik ze zdjęciami spełniający narzucone
          przez system warunki\\[0.2cm]
          \textbf{wyjście}: system tworzy nową galerię i wyświetla w panelu fotografa komunikat o jej utworzeniu oraz wysyła odpowiednią
          wiadomość e-mail do fotografa
  \end{itemize}

\section{Testy akceptacyjne}
Testy akceptacyjne służą akceptacji gotowej aplikacji przez klienta. Naszymi klientami będą fotografowie oraz użytkownicy chcący zamówić odbitki.
Dlatego najpierw przeprowadzone zostaną beta-testy. Do używania portalu zostanie zaproszona grupa fotografów, która za darmo będzie mogła
umieszczać zdjęcia w serwisie (który nie będzie jeszcze dostępny dla wszystkich użytkowników) i między sobą zamawiać odbitki tych zdjęć bez
konieczności płacenia za nie. Ma to być symulacja realnego wykorzystania systemu przez fotografów, którzy będą raportować zespołowi każdy
napotkany błąd, który będzie następnie poprawiany. Informacja o poprawieniu błędu będzie wysyłana do fotografa, który go zgłosił, aby mógł
sprawdzić, czy poprawka została wprowadzona poprawnie.


\section{Harmonogram testów}
Wszystkie testy będą przeprowadzane tak szybko jak to jest możliwe, aby jak najwcześniej wykryć błąd i poprawić go. Zapobiegnie to propagacji
tego błędu do późniejszych wersji kodu i zapewni jak najlepszą stabilność po ukończeniu projektu.

\subsection{Testy modułowe}
Testy modułowe są przeprowadzane przez autora bądź wyznaczonego programistę przez cały czas tworzenia kodu na bieżąco. Po napisaniu całej klasy
jest ona testowana też przez testerów.

\subsection{Testy integracyjne}
Testy integracyjne będą przeprowadzane od razu po ukończeniu modułu przez programistów, przetestowaniu go przez testerów i zgłoszeniu do
integracji z systemem. Są one niezbędne do pozwolenia na integrację modułu i mają chronić głównie przed błędnie integrującymi się z systemem
modułami.

\subsection{Testy systemowe}
Po zintegrowaniu wszystkich modułów realizujących jakąś funkcję portalu testerzy przystępują do jej testów, będących częścią testów systemowych.

\subsubsection{Testy interfejsu}
Częścią testów systemowych są testy interfejsu. Będą one przeprowadzane w ramach testowania poszczególnych przypadków użycia przy pomocy programu
\verb+HttpUnit+ automatycznie i ręcznie przez testerów tak szybko jak tylko interfejs będzie gotowy.

\subsection{Testy akceptacyjne}
Testy akceptacyjne, czyli faza beta portalu powinny trwać co najmniej 2 miesiące, a w razie potrzeby trochę dłużej, aby dać programistom czas
na poprawienie błędów. Dlatego portal powinien być ukończony i oddany do beta-testów już na $2.5$ miesiąca przed otwarciem go dla wszystkich
użytkowników.

\subsection{Testy wydajnościowe}
Na każdym poziomie testów: modułowym, integracyjnym i systemowym będą jednocześnie przeprowadzane testy wydajnościowe. Przeprowadzanie ich
na każdym poziomie ma pozwolić możliwie szybko wykryć zbyt wolne części systemu i w miarę możliwości poprawić ich wydajność.

\end{document}
